perm filename FRM.MSG[P,JRA]3 blob
sn#493087 filedate 1980-01-13 generic text, type C, neo UTF8
COMMENT ⊗ VALID 00028 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00004 00002 ∂11-Aug-77 0447 RPG New MACLSP
C00010 00003 ∂02-Nov-77 1616 JP MACLSP meta-D directory feature
C00012 00004 ∂06-Nov-77 1503 RPG New features.
C00014 00005 ∂24-Nov-76 1518 RPG Debug/Step (SAIL)
C00015 00006 ∂26-Nov-76 1324 RPG TRACE/STEP(SAIL)
C00016 00007 ∂02-Dec-76 1437 RPG NCOMPLR/TOPS-10
C00017 00008 ∂08-Dec-76 1514 RPG INPUSH/INPOP/SAIL
C00020 00009 ∂26-Feb-77 1624 RPG Eread
C00021 00010 ∂19-May-77 0118 JP running E from maclsp
C00022 00011 ∂01-Jul-77 2212 DCO MAIL in MACLSP
C00024 00012 ∂04-Dec-76 1321 FTP:GLS at MIT-AI (Guy L. Steele, Jr. )
C00032 00013 ∂28-Oct-76 2107 RPG BOOK
C00050 00014 ∂10-Nov-76 1351 RPG PROGV Feature
C00052 00015 ∂11-Dec-78 1724 RPG NEWIO programming tips
C00054 00016 ∂21-Dec-78 1219 RPG Bug fix in NEWIO
C00056 00017 ∂09-Jan-79 1542 RPG MacLisp matcher
C00059 00018 ∂17-Jan-79 1546 RPG UTIL.>
C00060 00019 ∂12-FEB-76 0845 FTP:GLS at MIT-AI
C00070 00020 ∂03-Mar-77 1603 FTP:GLS at MIT-AI (Guy L. Steele, Jr. ) Knight displays
C00074 00021 ∂27-Feb-78 1706 HPM more video
C00083 00022 ∂29-Oct-76 1101 RPG GRIND
C00085 00023 ∂14-Dec-76 2221 RPG Printing windows/SAIL
C00086 00024 ∂09-Jun-77 1415 RPG sewer OLDIO
C00088 00025 ∂02-May-78 1245 MG ML (LCF metelanguage)
C00105 00026 ∂19-Jul-77 1436 JP
C00106 00027 ∂06-Apr-78 1232 RPG New Maclsp
C00108 00028 ∂20-Jan-79 1754 RZ at MIT-MC (Richard E. Zippel)
C00122 ENDMK
C⊗;
∂11-Aug-77 0447 RPG New MACLSP
To: MACLSP.DIS[AID,RPG]:;
There is a new MACLSP running at SAIL, which has fancy
high segment capabilities such as
1. High segment stored on a separate file
2. Ability to fasload into the hiseg
3. Ability to create pure list space in hiseg
4. Ability to clobber uuolinks (for debuggin)
5. Ability to save high segments anywhere (and get them back under
all sorts of adverse conditions)
The documentation for the above will be available next week. If you
want to use these features, contact RPG.
∂02-Oct-77 2117 DCO MAIL
To: MACLSP.DIS[AID,RPG]:;
Minor update to MAIL in maclsp. (MAIL <destination> <message>)
evaluates <desination> and <message>, and mails the latter to the former.
e.g (mail 'dco x) will send whatever x is to me. (mail <desination>)
will prompt for the message. (mail) will prompt for both <destination>
and <message>.
∂11-Oct-77 1414 RPG
To: MACLSP.DIS[AID,RPG]:;
Modifications to Step (1 bug fixed; 1 feature added):
1. Use (step) as in the manual. That way (step t) inside a break
should work.
2. New feature: (step-hard ...) which is just like step EXCEPT it
works HARDER! Now, working harder is really true so don't use it
unless you need it. Here's what it does: suppose you have
(defun foo (n) ... (bar ...) ...) and foo is compiled and bar
isn't, and you want to step wherein bar. Well, since eval never sees
the compiled call to bar, ordinary (step (wherein bar)) will lose.
But, if you are stepping-hard, the stepper looks around the FIRST
chance it gets to see if it is inside of BAR; this means it searches
the control stack. If it is in bar it prints
<in BAR>
next-form.
-rpg-
∂21-Oct-77 1333 CGN MACLISP MACRO PACKAGE FOR RECORD STRUCTURES
To: MACLSP.DIS[AID,RPG]:;
I have finished a macro package written by Derek Oppen and myself to
facilite manipulating record structures with named components.
As an example, the call (SHELL MNODE COEF UP LEFT ROW COL) could be
used to "create a data-type MNODE" for sparse matrix nodes which has
five components, by defining access and update macros for the
components and an allocation function for MNODEs. You have your choice
between list-structure or MACLISP hunks for the underlying
representation.
The package is documented in SHELL.LSP[LSP,CGN].
∂02-Nov-77 1616 JP MACLSP meta-D directory feature
To: MACLSP.DIS[AID,RPG]:;
Subsribers of the HELP autodef package:
A new feature has been added to SAIL MACLSP to enable obtaining fast
directory listing using RPG's DIRECT fn. It permits use of >,#, and * as
wildcards. To access the package do when talking to MACLSP
βD <filespec> ;;; note: D not d!
where filespec is of the form filnam.ext[p,pn] and where ext,p,pn and the
syntactic delimiters can be omitted in the obvious cases. * wildcards are
allowed for for filnam and ext. If p or p,pn are omitted, they are
obtained from your current crunit device.
Ext can also be > and #. > obtains the largest numbered version, and # denotes
all numbered versions.
Ex:
*.#[lu,ser ;all files with numeric extension in [lu,ser
*.>[foo, ;the file with largest numeric ext in [foo,
*. ;all files w/o ext in crunit dir
...etc...
NOTE: No wildcards allowed in PPN!
∂06-Nov-77 1503 RPG New features.
To: MACLSP.DIS[AID,RPG]:;
There are two new features in maclisp which are callable
after (help) is performed.
1. (dir) returns a list of (filename <ext>) for your aliased ppn
2. (dir foo) returns a list of files for foo,pn
3. (dir foo bar) returns a list of files for foo,bar
4. (directory 'foo 'bar) returns a list of files for foo,bar
5. (dir /1 /1) returns a list of all known ppn's on the system (takes
a LONG time.
6. (esci-enb) enables [esc]i interrupt for the purpose of interrupting
running jobs. [esc]i<x> is equivalent to <call> reenter <x>,
but only works well when NOT in a read (i.e. will attempt
to complete the read first).
-rpg-
∂24-Nov-76 1518 RPG Debug/Step (SAIL)
To: MACLSP.DIS[AID,RPG]:;
DEBUG now knows about STEP in that while inspecting
stack frames, DEBUG will ignore all frames associated with the
single stepping facility.
∂26-Nov-76 1324 RPG TRACE/STEP(SAIL)
To: MACLSP.DIS[AID,RPG]:;
The Step package now UNTRACes any function it has to
single step through. Step will print a message informing the luser
of any UNTRACEs performed.
-rpg-
∂02-Dec-76 1437 RPG NCOMPLR/TOPS-10
To: MACLSP.DIS[AID,RPG]:;
The ncomplr now parses file names in winning line mode.
In addition, full decoding of files is now
available. Thus you can say:
FOO.FAS[LO,SER]←FOO.LSR[BLE,TCH](KT)
and all will be well.
∂08-Dec-76 1514 RPG INPUSH/INPOP/SAIL
To: MACLSP.DIS[AID,RPG]:;
The SAIL Maclisp now sports INPUSH/INPOP, which can be
used to do stack-structured input. Delicately based on the
IOPUSH/IOPOP/MTAPE UUO's at SAIL, they can be used as follows:
***FOO.BAR***
.
.
.
'CIAO
(INPUSH LOSING FLE)
'BACK-AGAIN
.
.
.
***LOSING.FLE***
.
.
.
'HI-THERE
(INPOP)
.
.
.
Then (EREAD FOO BAR DSK (LO SER)) produces:
.
.
.
CIAO
(DSK (LO SER)) ;value of (INPUSH ...)
.
.
.
HI-THERE
T ;due to (INPOP)
BACK-AGAIN
.
.
.
Notice that (INPOP) has to occur in the file: simply letting
(READ) run off the end fails! To remedy this, there is a function
called REQUIRE (given an autoload property by (HELP), which will
(PRINT (EVAL (READ))) everything in the file which is REQUIRE'ed.
It is called as: (REQUIRE LOSING FLE DSK (LO SER)) i.e. it has
the same arguments as UREAD. The NCOMPLR also knows about REQUIRE,
and the proper thing to do is:
(DECLARE (EVAL (READ))
(REQUIRE LOSING FLE DSK (LO SER))
which will work whether the file is being read or compiled.
I would discourage the use of these functions, however,
since they depend on black UUO magic and will possibly disappear
with the onslaught on NEWIO around Armageddon.
∂26-Feb-77 1624 RPG Eread
To: MACLSP.DIS[AID,RPG]:;
Eread, the E-file understanding version of Uread now accepts the
following:
(EREAD <file-name> {<ext> default: no extension}{<device> default: DSK}
(<proj> {<prog> default: prog of dskppn}))
where {} indicates optional args and defaults
∂19-May-77 0118 JP running E from maclsp
To: MACLSP.DIS[AID,RPG]:;
File ET.FAS[MAC,LSP] contains LSUBR ET that swaps to E from MACLSP.
Permissible incantations are
(et '(fil)) ;uses E default extensions in disk dir
(et '(fil ext)) ;disk dir
(et '(fil ext (prj prg)))
(et '(fil (prj prg))) ;default ext
(et) ;runs E on last file edited
Notice that the device is always assumed to be DSK.
Bugs, comments → JP
∂01-Jul-77 2212 DCO MAIL in MACLSP
To: MACLSP.DIS[AID,RPG]:;
MACLSP now accepts mail. If you have the (HELP) option, type
(MAIL) to enter the mail program. You will be prompted to give a destination
list and then the message, both of which must be surrounded by double quotes.
Here is an example of its use:
(MAIL)
Destination? (Any valid MAIL destination list surrounded by "s)
"DCO, RPG%SAIL"
Message? (surrounded by "s)
"Notice that a message may run over any number of lines and may contain
any characters. If you want a double quote in your message, type it twice
as in "". The message now ends."
It is generally faster to send mail using (MAIL) then to use the MAIL
monitor command because (MAIL) does not start up a separate job. The tradeoff
is that the mail is not delivered immediately, but waits until the remind
phantom checks if there is any incoming arpanet mail. This happens roughly
every ten minutes.
∂04-Dec-76 1321 FTP:GLS at MIT-AI (Guy L. Steele, Jr. )
Date: 4 DEC 1976 1620-EST
Sender: GLS at MIT-AI
From: GLS at MIT-AI (Guy L. Steele, Jr. )
To: jra at SU-AI
CC: GLS at MIT-AI
Message-ID: <[MIT-AI].34717>
I assume you meant "hunks". They are essentially a crock,
which I am not entirely proud of, to stave off the address space
crunch in the PDP-10 implementation of MacLISP.
They are essentially short vectors of fixed size; they have
no header as an array does (which occupies 8 words or so).
People generally use them to create small heterogeneous data
structures of more than two components. They take half the space of
a list, since no cdr pointers are needed. They will not
exist on the LISP machine implementation, as the cdr-code
notion yields exactly the same savings, more or less.
Hunks also provide slightly faster access than a list does, but
that consideration is secondary to that of space.
∂28-Oct-76 2107 RPG BOOK
I have finished the first part of the book and have the following
general comments:
The parts on data structuring seemed to me to be forced. It may
be that I have some residual bigotry on my part, but I felt that it
didn't roll to easily.
On the other hand, I felt that the sections on EVALuation and
spaghetti were among the best I have read in that area (i.e. excellent).
The implementations were quite understandable and the points were well
made.
More specifically, the comparison or analogy between mathematical
definitions and data structuring appeared to be very unnatural, although
I felt that the points made were good.
On spaghetti, my feeling is that it is undoubtedly something for
people who use LISP should know about, but it may not be something that
is ever useful in practice. I have personally never known anyone who has
used it in anything like a production program (except me), and almost none
who have even used it except to see how it works. It seems that there is
always a better way to achieve ones ends than by a general purpose &
inefficient features. Spaghetti invariably saves too much information, tends
to favor lexical variables (especially when you usually want fluid), and forces
laziness on the part of the hacker. For instance, I wrote a hairy pattern
matcher once which required real bactracking in a car/cdr recursion (not a
simple tree search). The matcher often had to bactrack into a control frame
that had been exited. Well, in LISP370 I used spaghetti, and in MACLISP I
explicitly used continuations, which clarified control and was fairly efficient
through the compiler. (the idea was to make the cdr recursion a sub-computation
of the car recursion as opposed to a sister computation). I plan to recode
the LISP370 version soon.
Another point concerns the use of continuations in the book. It
seems that they only appear briefly, as a passing concept between recursion/
subroutine returns and PC control. Well, either continuations should be
presented as a programming skill on its own, or it should be flushed as
a puzzling interlude, or some comment might be derived about its intermediary
position wrt stack control style and Program Counter style.
I am always puzzled about the use of a "LISP Metalanguage" which is
separate from the S-expression notation. I am not questioning the usefullness
of the metalanguage as a theoretical tool of great importance, but the
of it as a pedagogical tool. When I TAed 206 for McCarthy, I saw the
bewilderment it caused when the two notations were introduced in parallel.
A point this "algolishness" seems to obscure is the natural ambiguity inherent
in LISP, namely between the program and the data. Now, I am definitely
not trying to say that it is the ability of LISP to write programs and execute
them which makes i such a nifty language, but that the ability to cons up
certain restricted expressions which can be later applied on a small scale
(that is the handles on the evaluator) that make it a useful language.
A point that you don't seem to make is that LISP is an environment that
the user can sit inside of while his programs suffer trauma, and not a
compiler-based language in which you create your poooooor program, and boot
it into the confusing world of the compiler, tto suffer alone in the cruel
world.
I guess LISP is naturally a hacker's programming language, in that
every nifty hook is available, and you can either hang yourself or not
according to your own abilities.
An important aspect of any comprehensive discussion of LISP is why
it is that such an obscure looking language should be preferred by AI
hackers.
Well, I look forward to the next sections of the book, and will
put the commented first part in your mailbox, if you have one, or mine.
-rpg-
∂10-Nov-76 1351 RPG PROGV Feature
To: MACLSP.DIS[AID,RPG]:;
Here is a little known feature of Maclisp that may be of some
use:
(PROGV <VAR-LIST> <VALUE-LIST> <FORM1> <FORM2> ... <FORMN>)
EVALUATES <FORM1> ... <FORMN> AS A PROGN IN AN ENVIRONMENT
CREATED BY BINDING THE SYMBOLS IN <VAR-LIST> TO THE
RESPECTIVE VALUES IN <VALUE-LIST>. THAT IS, THE FIRST
TWO ARGUMENTS TO PROGV ARE EVALUATED; THE FIRST MUST
PRODUCE A LIST OF SPECIAL VARIABLES, AND THE SECOND
A LIST OF VALUES. THE VARIABLES ARE THEN BOUND TO THE
VALUES. IF TOO FEW VALUES ARE SUPPLIED, THE REST OF
THE VARIABLES ARE BOUND TO NIL. IF TOO MANY VALUES
ARE SUPPLIED, THE EXCESS VALUES ARE IGNORED.
THE BODY OF THE PROGV IS THEN EVALUATED AS A PROGN,
THE VARIABLES UNBOUND TO THEIR OLD VALUES, AND THE
VALUE OF THE LAST FORM IS RETURNED.
EXAMPLE:
(SETQ A 'FOO)
(SETQ B 'BAR)
(PROGV (LIST A B 'B) (LIST B) (LIST A B FOO BAR))
==> (FOO NIL BAR NIL)
∂10-Nov-76 1622 RPG Book
The static structure section is in my box.
I did not find it as well wriiten as the evaluator sections.
In particular the treatment of shallow binding was
misleading/incomplete.
-rpg-
∂11-Dec-78 1724 RPG NEWIO programming tips
To: "@MACLSP.DIS[AID,RPG]" at SU-AI
When compiling a file, if you want to do a require, just say:
(REQUIRE ...)
rather than the older:
(DECLARE (REQUIRE ...))
or whatever. NCOMPLR knows about REQUIRE.
The useful feature EVAL-WHEN can be used to do things in the compiler
environment much like a DECLARE:
(EVAL-WHEN (COMPILE) (DEFUN ZTESCH MACRO ...))
You can also have LOAD and EVAL appear in the options part as well as
the COMPILE. If EVAL and LOAD appear then the form will be EVALed at LOAD time.
(EVAL-WHEN (COMPILE) (DEFUN FOO MACRO (X) 'FOO))
is totally equivalent to
(DECLARE (DEFUN FOO MACRO (X) 'FOO))
and
(EVAL-WHEN (EVAL COMPILE) P1 P2 . . . PN)
is equivalend to
(DECLARE (EVAL (READ)))
(PROGN P1 P2 . . . PN)
finally, one wants a way to cause something to happen during loading
of the compiled code - that is what the LOAD options is.
(EVAL-WHEN (LOAD EVAL) (PRINT 'LOADING-MY-SYSTEM))
∂21-Dec-78 1219 RPG Bug fix in NEWIO
To: "@USERS.DIS[AID,RPG]" at SU-AI
A bug wherein part of the LISP reader believed itself to be
in linemode and part in character has been patched using partial
knowledge. This means that the patch may or may not work, and even
might cause further bugs. Things which could conceivably be effected
are input from non-data-disk/datamedia terminals, programs using
tyipeek, and some kinds of disk IO. Symptoms of further lossage could include
waiting for input when there shouldn't be any, reading too much stuff, etc.
-rpg-
∂22-Dec-78 1630 RPG DEFUN change.
To: "@USERS.DIS[AID,RPG]" at SU-AI
The first atom in a DEFUN is ALWAYS interpreted as the name of the function.
So in (DEFUN FEXPR MACRO ...) FEXPR is the name of the MACRO being defined.
-rpg-
∂09-Jan-79 1542 RPG MacLisp matcher
To: "@USERS.DIS[AID,RPG]" at SU-AI
Here's some changes to %MATCH you matcher fans:
;;;;;;;;;; the matching function ;;;;;;;;;;
;;;
;;; (arg 1) - p - pattern
;;; (arg 2) - d - data
;;; (arg 3) - alist - optional list of variables (* or ?) whose values
;;; are to be retained during the match, much like the
;;; = variables below.
;;; elements of a pattern:
;;; ? - matches anything
;;; * - matches one or more expressions
;;; ?<atom> - like "?", but sets ?<atom> to thing matched
;;; *<atom> - like "*", but sets *<atom> to list of things matched
;;; =<atom> - matched against value of <atom>
;;; (restrict <one of above ?-variables> <pred1> <pred2> .....)
;;; - the predi must eval to non-nil
;;; $r, ⊗r - same as RESTRICT
;;; (restrict <one of above *-variables> <pred1> <pred2> .....)
;;; - the predi must eval to non-nil when given the list
;;; that is being considered for that variable as its argument
;;; (irestrict <one of above *-variables> <pred1> <pred2> .....)
;;; - the predi must eval to non-nil when given each element of the list
;;; that is being considered for that variable as its argument
;;; (done incrementally). So %MATCH will apply these predicates as
;;; it scans the input.
;;; $ir,⊗ir - same as irestrict
;;;
;;; (%match p d <variables to retain>) attempts to match p against d
;;; (%continue-match p d <variables to retain>) attempts to get the next
;;; possible match between p and d (by different *-variable
;;; bindings.
;;*PAGE
∂17-Jan-79 1546 RPG UTIL.>
To: "@USERS.DIS[AID,RPG]" at SU-AI
To speed up compilation (and interpretation), you might try changing your
(require util 1 dsk (aid rpg)) to
(declare (fasload '((dsk (aid rpg)) util fas)))
-rpg-
∂12-FEB-76 0845 FTP:GLS at MIT-AI
Date: 12 FEB 1976 1143-EST
From: GLS at MIT-AI
To: jra at SU-AI
Be not discouraged. I intend fully to review the entire book.
As I said, I have hope that the last half will be much better.
I'm sorry if I seemed harsh in my letter. I will be quiet busy
for the next couple of weeks, but I think I can certainly mail
you reviewed chapters at the rate of one every three or four weeks
at worst. Would that be sufficiently fast for your purposes?
-------
∂12-FEB-76 0902 FTP:GLS at MIT-AI
Date: 12 FEB 1976 1200-EST
From: GLS at MIT-AI
To: jra at SU-AI
Well, now that I have a better idea of your audience,
I can do a better job of reviewing, I guess.
Maybe what mislead me was the title: "The Anatomy of LISP"
looks like it means a book about LISP. Maybe you want
something like "Computer Science: a LISP Approach",
except that that sounds like a tired cliche. "The Anatomy
of LISP" is a great title -- it's just that it's not
precisely what the book is about, in some sense.
But maybe I am picking nits.
I suppose that m-expressions are okay. I still say they are
hard to read. Maybe if you had a better font, and pretyy-printed them
better. I hope the printers have a good font. The major problems are
that the semicolons are italic, and would look better if vertaical;
and that the square brackets don't have enough space between them,
so they're hard to count.
While you may not want to use "top", I think it is still true that
one shouldn't confuse errors with non-termination. I don't see
how coalesced sums can possibly hurt you. Another way is to use
"super-bottom" and "super-top"; i.e., every domain has its own
bottom and top, and there is a special bottom below all other
bottoms, and similarly tops. But it is very confusing
to say that bottom means "undefined", and later to say "[43 -> x; y]
isn't 'bottom' -- it's *really* undefined".
-------
∂03-Mar-77 1603 FTP:GLS at MIT-AI (Guy L. Steele, Jr. ) Knight displays
Date: 3 MAR 1977 1904-EST
Sender: GLS at MIT-AI
From: GLS at MIT-AI (Guy L. Steele, Jr. )
Subject: Knight displays
To: jra at SU-AI
CC: GLS at MIT-AI
Message-ID: <[MIT-AI].70877>
Well, a Knight display terminal consists of a TV monitor and
a separate keyboard (made by Microswitch). The TV gives something
like 450 by 380 raster (i forget exact figures); using a 6x12
character matrix, this gives 96 chars wide and 37 or so lines.
The TV screen is repetitively refreshed on a bit basis from
a memory.
There are far more terminals than can be used at once - they are cheap
enough to have one in every office, naturally. There are
14 "video buffers" of 16K 16-bit words apiece (room for
expansion to 16 buffers). There is a crossbar (the video switch)
which connects bit sources to bit sinks (16x32). Currently
the only sources are the video buffers, and sinks include all
the terminals and a Tektronix copier.
The video buffers hang off a unibus interface on a PDP-11.
A register controls which one is accessible to the unibus
(the PDP-11 also has 12K of normal memory). The PDP-11 in turn
hangs off the MIT-AI pdp-10 to pdp-11 inteface, which makes
PDP-11 memory addressable from the PDP-10. In this way
a user program, after making a number of system calls, can
write directly into the bits of the TV screen:
the user memory refeence is mapped by the paging box to a magic
address in high memory (location 2,,xxxxxx); the 10-11 interface
maps it to the correct PDP-11; the unibus interface maps it
to the correct TV buffer; and voila!
The unibus interface for the buffers has an ALU inside of it
which is sometimes useful; it can do an IORM faster for you
than the PDP-10 can.
The kayboards are similar to Stanford keyboards,
but I think have a few more keys. They generate 15 bits
(64 code-generating keys @ 6 bits, shift lock, and left/right
each of ctrl/meta/top/shift). The PDP-11 immediately folds this to 12
bits (top,shift lock, shift, meta, ctrl, and 7 bits of ascii)
and passes it to the PDP-10. User programs can read them
in 12-bit or 7-bit mode. User programs that read 12 bits
conventionally fold them down to 9 bits (meta, ctrl, ascii)
though they don't have to.
that answerthe question? if not, tk@ai himself can probably helpp more.
-- Guy
∂27-Feb-78 1706 HPM more video
1. the xgp-to-gray sacle algorithm ( i know you told me once, but
(blush, blush) i forgot.
2. given the gray scale channels, how much smoothing does the
video synthesizer do.
*******
imagine a page of XGP output. It is 8 1/2 by 11 inches and has 200
dots per linear inch in each direction, each dot being black or white.
Call a black dot a 1 and a white spot a 0. The page is then an array
of 2200 rows and 1700 columns of bits.
Each data disc channel is conceptually organized into 480 rows and 512
columns of bits. There are 32 of these channels altogether, all producing
bits simultaneously. Normally they are used to operate 32 different tv
screens, each a 480 by 512 by one bit display. Eight of these channels go
to a digital to analog converter. This D/A is thus provided with eight
bits for each of the 480x512 points on a TV screen. It takes these
8 bits and translates them to one of 2↑8 grey level values. Thus the
output of the D/A is a tv image with 480x512 samples, each one of 2↑8
shades of grey. The data-disc:D/A converter is called the video
synthesizer. There is no additional smoothing except perhaps that
caused by the limited frequency response of the video amplifiers
anlong the way to your TV screen, and by the finite spot size of
the electron beam in your CRT.
The XGP dot array is more than three times as wide the data disc
array, and more than four times as tall. Also, the TV screens are
wider than they are tall, making them just about right for displaying
a half page of XGP output. A half page is still over 3 times as wide
and 2 times as tall as the DD array. By throwing away some of the
(hopefully) blank border on the page, the ratios are made exactly
3 and 2. So now imagine that each DD dot must somehow represent
a little 3 by 2 subarray of the XGP array. If we sum up the number
of 1's in each of these subarrays, we get numbers from 0 to 6.
If 0 represents white and 6 represents black, with the numbers
in between representing proportional shades of grey, we can display
the resulting pattern on the video synthesizer. It looks like
a blurred version of the XGP page. That's half density XGPSYN.
Full density turns the page on its side and compresses the
page length by a factor of 4 (instead of 2) and the width by
3, as for half density. Double density does 4 lengthwise and
6 sideways (giving numbers from 0 through 24).
The simple summing over subrectangles is a filtering. Other
more complicated filtering algorithms, that involve shading some
adjacent dots, might give even better results [CACM V20 #11 799:805].
*******
3. where, oh where, might i find the video synthesizer details
and even perhaps the xgp synthesizer listings?
*******
The source for XGPSYN is XGPSYN.SAI[PIX,HPM], though I don't think
it will be too helpful.
*******
these and other questions can only be answered by YOU.
besides, the gratitude of the huddled masses, I'd even autograph
a copy of my forthcoming (and outgoing) LISP book.
*******
wow!
*******
i await pregnantly,
john
COMMENT ⊗ VALID 00001 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00002 ENDMK
C⊗;
∂29-Oct-76 1101 RPG GRIND
To: MACLSP.DIS[AID,RPG]:;
The MACLISP grinder now understands E-files. Grinding an E format
file will cause the directory to be flushed.
-rpg-
∂29-Oct-76 1824 RPG BIBOPIZATION
To: MACLSP.DIS[AID,RPG]:;
MACLSP is now fully BIBOPized and SAIL housebroken.
MACLSP, NCOMPLR, & SCHEME all run under BIBOP; MACLSP IO routines
understand E-format files. This includes NCOMPLR and the GRINDer.
Don't forget to use EREAD in place of UREAD for all normal disk IO.
(This is the routine that understands E.)
-rpg-
∂01-Nov-76 2201 RPG BIBOP
To: MACLSP.DIS[AID,RPG]:;
Don't forget, R MACLSP invokes the latest BIBOP version
of MACLISP.
-rpg-
∂14-Dec-76 2221 RPG Printing windows/SAIL
To: MACLSP.DIS[AID,RPG]:;
One can now print the window surrounding a CE by
saying "W" to the Editor. If the windowsize is 2, then the
2 tokens preceeding the CE, the CE, and the 2 tokens following
the CE are printed (a token is an expression or a parenthesis).
The windowsize is set by (WINDOW n).
∂09-Jun-77 1415 RPG sewer OLDIO
To: MACLSP.DIS[AID,RPG]:;
At SAIL Maclisp has been modified as follows: ordinary disk file
IO now uses 6 buffers in the input (output) buffer rings and fasload reads
1400(8) words at a time from disk in dump mode while fasloading. Since the
bottleneck at SAIL is the disk right now these changes will greatly
improve the performance of Maclisp AND the rest of the lusers on the
SAIL machine. However, there are a few things to watch out for:
1. the correctness of Require in this new scheme has not been proven.
2. BPS will need to be increased for fasload. Essentially fasload
uses array space for its dump mode buffering. So, the increased size
(200 to 1400 (8)) means that BPS should be about 1200(8) [640.] words larger
than before. You ought to go through your *.ini files and make this
update or face "no core -- array" errors.
-rpg-
∂10-Jun-77 1145 JP E - MACLSP - E
To: MACLSP.DIS[AID,RPG]:;
ET.FAS[MAC,LSP] has been modified so ⊗XRUNning from E returns you
to the calling MACLSP image. LSUBR ET now returns nil. Comments → JP
COMMENT ⊗ VALID 00001 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00002 ENDMK
C⊗;
∂02-May-78 1245 MG ML (LCF metelanguage)
To play with ML do "R ELCF" then when you get the LISP prompt
* do "(TML)" (u.c.) and then respond with <return> to both "THEORY?"
and "DRAFT?".e.g. simulated interaction:
.r elcf
*(TML)
LCF version 5 issued 27-oct-77
(with simultaneous substitution and new simplification)
THEORY?*
DRAFT?*
* .......
.........
..........etc.eg
.
.
.*letrec map fn l = null l => [] | (fn (hd l)).map fn (tl l));;..
----------------------------------------------------------
The ML prompt should be "#" but to do this needs (DE PROMPT (N) ...?...)
--eg see PROMPT[LCF,FWH] for the Edinburgh hack.
See yah....Mike
∂02-May-78 1258 MG erratum
"fn(hd l).map fn (tl l)" is more correct - ihad an extra bracket before
∂19-Jul-77 1436 JP
To: MACLSP.DIS[AID,RPG]:;
SAIL MACLSP interprocess communication
A preliminary version of a MACLISP interjob communication facility is
available to those of you lusers subscribing to the (help) autoload
facility. These functions permit arbitrary creation, deletion,
synchronization and intercommunication of MACLISP processes. For more
information read FASFRK.JP[LIB,LSP].
-j
∂06-Apr-78 1232 RPG New Maclsp
To: MACLSP.DIS[AID,RPG]:
Warning! LISP 1525 has been installed, the first new assembly
since September 1977. At the next opportunity you should re-make any
systems based on Maclisp as well as reassemble any LAP code which
does file IO. Also, you should READ LSPARC (the first 3-4 pages) to
learn of the changes in this version. Good luck.
-rpg-
∂07-Apr-78 1018 RPG *rset
To: MACLSP.DIS[AID,RPG]:
Remember, the default for *rset in MacLisp 1525 is t, not nil as
in all previous versions. Also, LISP.INI files, if present, are automatically
loaded.
-rpg-
∂07-Apr-78 1624 RPG Lisp 1525
To: MACLSP.DIS[AID,RPG]:
Compiled hunk code appears to lose in MacLisp 1525.
If this will effect you, use sys:maclsp.old.
-rpg-
∂07-Apr-78 1809 RPG Hunk bug in MacLisp 1525
To: MACLSP.DIS[AID,RPG]:
Re-compile all files which use hunks.
-rpg-
∂20-Jan-79 1754 RZ at MIT-MC (Richard E. Zippel)
Date: 20 JAN 1979 2056-EST
From: RZ at MIT-MC (Richard E. Zippel)
Sent-by: RLB at MIT-MC
To: JRA at SU-AI, carl at MIT-AI
CC: RWK at MIT-MC, RLB at MIT-MC, HIC at MIT-MC, RZ at MIT-MC
This is to inform you that some subset of us will be submitting a
paper for the August issue of BYTE. The title will probably be
something like "LIL - A Lisp Implementation Language". We will
present a Lisp based compiler for implementing system software.
With the language (compiler and perhaps interpreter) embedded in
a Lisp-like environment, the user will have access to the Lisp
debugging tools. We feel that the ability to manipulate programs
via macros coded in Lisp will speed the code writing phase. This
language should be usable on micro-processors without difficulty.
Here is a preliminary outline of our proposed LIL paper. It would help us
a lot if you could give us some idea of how much space we can expect for
this paper, and how many diagrams it would be good to include, and of course
the deadlines.
Preliminary LIL paper outline
1. WHY MESS WITH LIL?
a. Motivation - what is an implementation language? Why do we need one?
b. LIL is not X for X in {LISP, BLISS, C, Pascal, PL/I, assembler, etc.}
c. Post parse-time macros (as opposed to textual substitution pre-parse-time
macros)
i. Used for user-extentions to the control structure of the language
ii. Used to extend the semantics of the language
iii. Used to extend the data structures which the language can handle.
d. Debugging aids via interpretation in LISP.
e. Stand alone debugging aids.
f. Extra control structures not found in other languages.
2. WHAT IS LIL?
a. Overture - What LIL offers, generally - functions, variables, pointers,
special forms (control-sturcture contstructs)
b. Syntax - what there is of it
i. lexical scan is easy, (), prefix characters ".' - symbols/number
ii. parse is trivial, explicit list notation
iii. all built into LISP's READ function.
c. Basic semantics
i. Function calling
ii. Variables
iii. . and ' (pointer-follower and address prefix)
d. Special forms (case, select, do, cond, and, or, etc.)
e. Macros - written in LISP, not LIL!
i. LISP is a good language for manipulating LIL code. (Or other code)
ii. Full interpreter available in the compiler.
f. Micros down to machine code level.
i. Give hands-on access to special capabilities of the host machine
ii. Enforce transportability; all machine-dependent code is in the form
of micros; these can be re-coded for new machine, the machine
dependencies have been isolated.
iii. Full user-control of compilation
g. User-defined optimizations.
3. COMPILER
a. Why write compiler in LISP
b. Optimization
4. INTERPRETER
a. Incremental debugging
b. Single step debugging, at source-code level, not machine-level.
c. Why you want both a compiler and an interpreter
5. COMPARE & CONTRAST LIL WITH OTHER IMPLEMENTATION LANGUAGES
a. Detail here that couldn't be included in section 1.
b. Sample program expressed in several such languages
(Perhaps do the core of a BASIC interpreter)
c. BLISS as LIL; show how LISP makes language manipulations easy
6. EXAMPLE AND DESCRIPTION OF WHAT WE'VE IMPLEMENTED
a. Not a lot yet, but we're trying.